home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19970326-19970626
/
000159_news@newsmaster….columbia.edu _Sun May 4 13:49:01 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
3KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA09928
for <kermit.misc@watsun.cc.columbia.edu>; Sun, 4 May 1997 13:49:01 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA02912
for kermit.misc@watsun; Sun, 4 May 1997 13:49:01 -0400 (EDT)
Path: news.columbia.edu!panix!news.mathworks.com!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: NULs and [MS-DOS, sigh] Kermit
Message-ID: <1997May4.110329.97781@cc.usu.edu>
Date: 4 May 97 11:03:29 MDT
References: <336ac4b2.0@duster.adelaide.on.net>
Organization: Utah State University
Lines: 45
Xref: news.columbia.edu comp.protocols.kermit.misc:6982
In article <336ac4b2.0@duster.adelaide.on.net>, behoffski@grouse.com.au (behoffski) writes:
> We're using MS-DOS Kermit, version 3.15 Beta 18, to observe the
> behaviour of various embedded systems. In a couple of cases recently,
> we've discovered glitches in the embedded systems due to the NUL
> character being sent or received by an ASCII-based protocol driver.
>
> We've noticed that Kermit's VT320 emulation does not display
> NULs by default, nor are these characters logged to file.
That is correct. NUL is a control code. The first 32 codes in
the ASCII character set are control codes and are not printable. Most
control codes result in commands to the terminal (emulator) to perform
some action rather than just display a byte. For DEC VT terminals the
action of NUL is to consume time as a line-filler byte, padding as it is
known. Putting padding into log files is not a good idea and MSK avoids
doing that. For Data General and Wyse 50 terminals NUL is a formal data
byte in control sequences and not padding, hence it is logged as well as
acted upon for those emulations.
> The lack of
> a display does not worry us; the lack of the character in the log file
> has helped trick us into missing the problems for quite a while.
>
> If session debugging is enabled (set debug session), then NULs
> are displayed and are logged. However, we'd prefer to use a standard
> VT-style terminal emulation without seeing debugging information.
> Is there an easy way to modify Kermit's behaviour so that NULs are
> always logged to file?
The DEBUG facility bypasses the machinery responsible for emulating
various terminal types. It is a raw simple "show me everything" diagnostic,
and as such is aligned with what your testing is intended to accomplish.
Given the decreasing amounts of equipment which generate as well as
need NUL padding bytes I'll change the next beta of MS-DOS Kermit 3.15 to
log the NUL byte for DEC VT terminal emulation and hope there are no
objections. Expect to see the change in beta 21 in a few days.
Joe D.
> thanks,
>
> behoffski
> Brenton Hoff (behoffski) | Software Engineer, Grouse Software Pty Ltd
> behoffski@grouse.com.au | My opinions are mine (and they're weird).